The Advanced Configuration and Power Interface (ACPI) specification is a document that describes ACPI hardware interfaces, ACPI software interfaces and ACPI data structures that, when implemented, enable support for robust operating system (OS)-directed configuration and power management. By using the ACPI specification, various computer systems and components that handle or implement power management states may be made compatible, even if such components are provided by different manufacturers.
Versions 1.0 and beyond of the ACPI specification define a well-known and widely-used set of power management states. State S0 is the “working” state for a computer system, wherein the computer's hardware is generally receiving full power. States S1-S3 are different levels of “sleeping” states where power to certain components is reduced, and context information required to return the system to the S0 state is stored in system RAM. State S4 is a “hibernate” state where the system is largely powered down, and where the context information required to return the system to the S0 state is stored in a hibernation file on some form of non-volatile storage (e.g., hard disk, NVRAM, etc.). State S5 is the “off” state where no context information is kept and the operating system must “boot” in order for the computer to return to the S0 state.
According to the ACPI specification, implementation of a particular system state requires that an object designating the power state exist at the root of the ACPI namespace. The object has the name _Sx, where x is from 1 to 5, thereby referring to the sleep and off states provided by the ACPI specification. For example, \_S3 corresponds to the S3 state. In addition, each object contains a DWORD having 4 bytes, where 2 bytes are reserved, 1 byte represents the command for a PM1a control register and 1 byte represents the command for a PM1b control register. For an operating system to transition the system to a sleep or off system state, the operating system writes the above-mentioned bytes to the appropriate register(s).
While the system state management provided by the ACPI specification is adequate for transitioning a system between any of the above-discussed power management states, it is severely limited in its ability to permit a developer to create new system states or to modify existing states. Developers may wish to design new system states that are a combination of existing states (e.g., a combination of S3 and S4), or a system state that is entirely new. In such a manner, power management can be tailored to advances in device and software development. The current ACPI system state naming scheme (i.e., the namespace) is unable to adequately provide for such new system states, however.
For example, the names of the ACPI states (e.g., S0-5) have a predefined meaning and provide an ordering mechanism to the operating system that the operating system uses to search for the most appropriate state when a system state transition is to occur. As a result, no room has been left in the ACPI system state namespace to add new system states. In addition, the meaning of the ACPI system state must be built into the software that references the state. In other words, the name of the state (e.g., “S3”) conveys information to the software instead of any data contained within the ACPI object. Thus, if a developer created a new system state, any software that is to use the system state would have to be updated. With the widespread proliferation of computer systems and software applications, such a solution would be cumbersome and time-consuming. Even if creating new system states (and updating all software that use the new states) were practical, the current ACPI naming scheme, or namespace, could only accommodate 250 new states (i.e., \_S6_to \_SFF), which may not be sufficient for the wide variety of devices and applications that are available currently and in the future.
The ACPI namespace is also limited by a developer's inability to add additional data to an existing _Sx object, because such an object contains a single DWORD. Other than 16 reserved bits within the DWORD that are too small to be of practical value, the object does not contain extra storage space for additional information. Furthermore, the data type of the DWORD cannot be changed without rendering the changed object incompatible with legacy ACPI-compliant operating systems.
Accordingly, there is a need for a mechanism for enabling power management states that are not supported by the ACPI specification while maintaining interoperability with systems that adhere to the specification. The present invention satisfies this need.